Git workflow
Кратко о git
Вкратце рассмотрим структуру git - популярную системы контроля версий. Она позволяет совместно работать над проектом множеству разработчиков. В большинстве workflow есть некоторый единый удаленный репозиторий, который хранит в себе все изменения от всех разработчиков. У каждого разработчика есть локальный репозиторий, синхронизация репозиториев происходит с помощью push и fetch команд. Кроме локально репозитория у разработчика есть индекс (некоторая база отслеживающая файлы и изменения в них) и workspace. При создании нового файла его сначала нужно добавить в index командой git add, а потом создать коммит git commit. Откатиться на изменения в индексе или локальном репозитории можно командами checkout и checkout HEAD. Сравнить состояние workspace можно командами deff и diff HEAD. Команды pull и rebase позволяют подтягивать изменения с удаленного репозитория сразу и в локальный репозиторий, и в workspace. В целом это основной набор команд, который вам пригодиться и ими вы чаще всего будете пользоваться при работе с git.
Какие workflow существуют?
Сегодня мы рассмотрим 4 подхода: git, github, forking flow подходы, используемые в разработке, data science lifecycle process это уже некоторая попытка адаптировать flow под исследования.
Gitflow
Gitflow одна из первых методологий управления проектом направленное на периодические, не частые релизы. В ней есть основная ветка master, в которой хранятся все релизы. До релиза разрабатываемый код находится в ветке develop. Каждое нововведение (фичу) один разработчик разрабатывает в отдельной ветке, после этого она сливается с веткой develop. Когда выполнен весь объем фич для релиза, из develop создается ветка release, в которой ведется доработка релиза и потом она вливается в master и тегируется, а также вливается в develop. Теги отвечают за версии релизов. В случае обнаружение багов в релизе появляется ветка hotfix в которой исправляются ошибки и она снова вливается в master и develop.
Как видите, методология достаточно тяжеловесная и применима в основном в enterprise разработке, так как она подстраивается под большинство фреймворков управления проектов по водопадной модели. В исследования применить такую методологию можно, но в результате вы получите очень много overhead для проекта по управлению ветками.
Github flow
Github flow это модификация gitflow предложенная github. Она направлена на снижение количества веток и упрощение поддерживания проекта. В ней оставаться две ветке - master и feature. Разработка новой функциональности проводится в отдельной фича-ветке, после этого происходит merge в master, после этого происходит новый релиз проекта.
Эта методология построена для проектов, управляемых в различных гибких методологиях. Одной из важных рекомендаций авторов, является открытие merge request заранее и обсуждение в нем различных моментов заранее, до окончания работ. В целом методология достаточно легковесная и гибкая, может подойти для проведения исследований, но в исследовании нет потребности в такой частоте релизов на начальных этапах.
Forking workflow
Forking workflow это методология поверх github workflow для разработки opensource проектов. Основная сложность в opensource связана с тем, что изначально доступа к изменению в репозитории проекта у потенциального контрибьютора нет, поэтому ему предлагается следующая последовательность шагов:
- Разработчик «разветвляет» «официальный» серверный репозиторий. Это создает их собственную копию на стороне сервера.
- Новая серверная копия клонируются в их локальную систему.
- В локальный клон добавлен удаленный путь Git для «официального» репозитория.
- Создана новая локальная ветка функции.
- Разработчик вносит изменения в новую ветку.
- Для изменений создаются новые коммиты.
- Ветвь помещается в собственную серверную копию разработчика.
- Разработчик открывает запрос на перенос из новой ветки в «официальный» репозиторий.
- Запрос на перенос утверждается для слияния и объединяется в исходный серверный репозиторий.
Таким образом организована разработка в opensource проектах. Могу сказать, что данная методология для исследований подходит плохо, из нее можно позаимствовать идею раздельных репозиториев, что если в команде много исследователей, то возможно их нужно разнести по разным репозиториям и периодически вытаскивать полезные нововведения в “официальный” репозиторий.
Datascience lifecycle project
Мы познакомились с процессами управления гитом распространенными в разработке, теперь перейдем к ds методологиям. Основными отличительными поинтами являются следующие утверждения:
- Большая часть кода, который вы пишете, выбрасывается; его ценность заключается в полученных знаниях, а не в самой функциональности.
- Часто бывает сложно заранее узнать, как выглядит готовое изделие.
- Результат эксперимента сильно зависит от данных и их качества.
- Хотя мы не хотим объединять весь наш код в основной, мы не хотим и выбрасывать его.
Основываясь на этих поинтах была разработана методология Datascience lifecycle project. Давайте быстренько пройдемся по нововведениям.
Data branch
Вводятся различные ветки, например есть data branches, в которых реализуется код для обработки данных, пишется отчет об этом и тесты для кода. На слайде представлена последовательность действий в такой ветке.
Explore and experiment branches
Для исследования данных предлагается использовать explore branches. Эти ветки остаются висеть в истории гита без мерджа, потому что код, который проводит исследование нужен разово, чтобы подтвердить или опровергнуть гипотезу.
Для экспериментов есть две стратегии, если эксперимент опроверг подход, то такая ветка не получает merge request и просто оставаться висеть в истории, так как знания о неудачных экспериментах тоже важны и влияют на принятие следующих решений в развитии проекта.
Для успешного эксперимента ветка переходит в ветку моделей.
Model branches
Когда был найден удачный подход то появляется новая ветка model branch в которой происходит настройка и исследование модели, а также написание отчетов и тестов. После этого происходит влитие ветки в master branch и релиз модели.
Хорошая методология?
Плюсы
- В основной ветке только важный код.
- Сохраняется информация о всех исследованиях.
- Имеет “логичные” разделения веток для разных задач.
Минусы
- Сложно автоматизировать воспроизведение всех исследований.
- Информация об исследованиях “размазана” по репозиторию.
- В теории выглядит хорошо, а на практике…
Методология конечно неплохая, но сильно оторвана от реальности. По факту в проекте большая часть работы связана с обработкой и подготовкой данных, так как чистые датасеты вы встретите только на kaggle, в реальности придется очень долго разбираться с данными и возвращаться к ним постоянно. Поэтому хотелось бы как-то просто обновлять результаты уже проведенных исследований.
В целом методология рабочая, но больше подходит для уже существующего проекта, где есть собранные и подготовленные датасеты и основной задачей является моделирование.
Выводы
- flow должен быть удобным команде
- не надо его перегружать, если нет необходимости
- иногда, не надо пытаться сразу объединять все результаты исследований
Самое важное не то какую методологию вы выберите, а то что вы этой методологии будете следовать всей командой. Все эти git workflow направлены на унификацию процесса развития проекта с точки зрения гита.
На мой взгляд наиболее рабочей методологией будет github workflow, с оговоркой, что релизом будет не каждый merge в master, а тег. Все остальное с названиями веток и прочим, большой когнитивный оверхед для работы исследователей.